Multithreading environments allow different parts of a process, known as threads, to execute simultaneously. Multithreading processes must be carefully designed so that all of the threads can execute simultaneously without interfering with each other.
As a thread executes, data must be maintained to indicate the current state of the operations being performed by the thread. This information is generally referred to as a runtime context. The runtime context of a thread includes all of the information associated with the execution state of that thread including, for example, local data, memory and system resource information such as database server connections.
In database applications, clients submit requests to a database server to perform operations on a database. Such operations may, for example, cause the database server to retrieve a particular set of data from the database and send the data to the client. Database applications in which an application server can concurrently service more than one client are referred to as three-tiered database applications.
In three-tiered database applications, multithreading is frequently used to reduce transaction processing time. Each client process may employ several threads, each of which establishes and maintains its own connection to a database server for performing operations specified by a transaction. In some circumstances, processing a transaction with multiple threads can be much faster than processing the same transaction using a single thread within a process.
Despite the favorable performance advantages offered by multithreading, the multithreading approach is not without its disadvantages. In some multithreading environments, runtime context information, such as database server connections, cannot be shared between threads. As a result, each thread must establish and maintain its own runtime context, including any database server connections, requiring significant system resources each time a new thread is spawned.
In addition, in some multithreading environments, the runtime context associated with a thread is lost when the thread terminates--either abnormally (because of an error) or by design (because a unit of work has been completed). Consequently, when a thread terminates prior to the termination of the program to which the thread belongs (transient thread), a runtime context must be properly re-established for another thread, since the runtime context associated with the terminated thread is lost and cannot be used to resume processing from where the terminated thread stopped processing. Re-establishing a runtime context might require re-executing the operations already performed by the terminated thread.
In view of the benefits provided by multithreading and the limitations in prior multithreading approaches, a multithreading approach which provides for the sharing of runtime context information between threads is highly desirable. In fact, even a single threaded application might find it convenient to establish and use multiple runtime contexts, especially when isolation between multiple database transactions is necessary.